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Executive  Summary 

This  document  is  the  final  report  of  a  project  to  review  the  new  Guidelines  on  the  Preparation  of  a 
Statement  of  Operational  Requirement  (SOR)  from  a  Human  Systems  Integration  (HSI) 
perspective.  The  project  was  sponsored  by  the  Defence  Research  and  Development  Branch 
(DRDB)  Work  Unit  6K,  using  Armour  Systems  projects  as  an  example  at  the  request  of  the 
Directorate  of  Land  Requirements  3  (DLR  3).  The  project  has  been  completed  by  Humansystems 
Incorporated  (HSI)  under  contract  to  the  Defence  and  Civil  Institute  of  Environmental  Medicine 
(DCIEM). 

This  report  was  developed  to  provide  some  guidance  for  addressing  the  Human  Systems 
Integration  content  requirements  of  DND  SORs  and  to  discuss  the  options  for  electronic 
distribution  of  HSI  related  information.  It  is  the  first  of  three  reports  developed  under  this  project. 

In  general,  the  inclusion  of  HSI  related  requirements  in  SOR’s  appears  to  be  straight  forward  based 
on  a  systematic  analysis  of  future  systems,  within  the  context  of  future  scenarios  and 
operational/support  concepts.  It  is  recognized,  however,  that  it  will  take  time  for  such  analysis  to 
become  practiced  and  routine  throughout  all  DND  environments.  It  is  recommended  that  the 
DRDB  community  support  any  efforts  to  ensure  that  HSI  is  included  in  SOR’s  over  the  next 
several  years  and  that  early  samples  be  provided  on  the  HSI  Web  Site  as  examples  for  other 
projects  to  learn  from. 

In  addition,  it  is  recommended  that  the  feedback  on  SOR  structure  and  content  related  to  HSI  issues 
outlined  in  this  report  be  integrated  into  future  versions  of  the  SOR  template  and  associated 
guidelines. 

This  project  has  concluded  that  the  basic  process  for  analysis  and  validation  of  HSI  related 
requirements  is  known,  however,  a  more  detailed,  integrated,  HSI  process  is  still  required.  It  is 
recommended  that  such  a  process  be  developed,  and  it  is  recognized  that  DND  is  already  initiating 
efforts  to  do  so. 

It  has  also  been  concluded  that  the  key  to  conducting  an  integrated  analysis  is  to  use  techniques  and 
tools  that  allow  a  core  analysis  of  (i)  Operational  Experience,  (ii)  Scenarios/Functions/Tasks,  and 
(iii)  Workstations  or  Interfaces  to  be  shared  by  each  of  the  domains  of  HSI.  This  shared 
assessment  increases  the  efficiency  and  accuracy  of  analysis  and  ensures  that  all  requirements  are 
kept  up  to  date  throughout  the  acquisition  cycle.  It  is  recommended  that  tools  and  techniques 
continue  to  be  developed  to  facilitate  the  sharing  of  analysis  between  these  three  primary 
assessment  areas,  and  it  is  recognized  that  DND  is  already  initiating  efforts  to  do  so. 

It  is  recommended  that  the  Armour  community,  in  conjunction  with  other  militaiy  environments, 
consider  the  conversion  of  the  Soldier’s  Day  software  tool  to  a  web  based  product,  with  the 
introduction  of  an  add  on  module  for  building  SOR’s.  This  solution  is  preferable  to  simply 
creating  annotated  bibliographies  accessible  on  the  Intranet,  however,  both  electronic  distribution 
mechanisms  could  be  introduced  in  parallel. 
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1  Introduction 


This  document  is  the  final  report  of  a  project  to  review  the  new  Guidelines  on  the  Preparation  of  a 
Statement  of  Operational  Requirement  (SOR)  from  a  Human  Systems  Integration  (HSI) 
perspective.  The  project  was  sponsored  by  the  Defence  Research  and  Development  Branch 
(DRDB)  Work  Unit  6K,  using  Armour  Systems  projects  as  an  example  at  the  request  of  the 
Directorate  of  Land  Requirements  3  (DLR  3).  The  project  has  been  completed  by  Humansystems 
Incorporated  (HSI)  under  contract  to  the  Defence  and  Civil  Institute  of  Environmental  Medicine 
(DCIEM). 

1.1  Background 

During  the  period  1994  to  1999  a  number  of  activities  conducted  by  the  Defence  Research  and 
Development  Branch  (DRDB)  focused  on  the  level  of  Human  Systems  Integration  (HSI)  analysis 
in  the  acquisition  and  development  process  These  efforts  culminated  in  1998  with  a  project  that 
generated  a  proposed  new  template  for  the  Statement  of  Operational  Requirements  (SOR).  At  the 
request  of  the  Directorate  of  Business  Change  Management  (DBCM)  this  SOR  template  was 
merged  with  another  proposed  SOR  template  to  create  the  new  “Guideline  on  the  Preparation  of  a 
Statement  of  Operational  Requirement”,  which  also  included  a  recommended  process  for 
determining  and  validating  requirements  on  an  acquisition  project. 

Throughout  1999  the  defence  acquisition  community  has  adopted  the  new  SOR  template.  The 
Vice  Chief  of  Defence  Staff,  through  the  Defence  Management  System  (DMS)  produced  by  the 
Directorate  of  Force  Planning  and  Project  Coordination  (DFPPC),  now  directs  project  staff  to  the 
new  SOR  guideline  hosted  on  the  DBCM  2  intranet  site. 

The  new  SOR  template  includes  Human  Systems  Integration  (HSI)  requirements  in  several  areas 
including:  Missions  and  Scenarios,  Key  Roles,  Key  Tasks;  User  Characteristics;  Crew  Station  and 
Interface  Design;  User  Acceptance;  Operability;  Survivability;  Maintainability;  Safety  and 
Health;  Performance  Measures;  Personnel  and  Training  Requirements. 

This  breakdown  of  human  factors  into  the  topics  listed  above  may  change  the  nature  of  the 
demand  for  HSI  information  (requirements,  specifications,  performance  measures)  for  future 
acquisitions.  For  example,  the  Soldier’s  Day  database  is;  a  software  tool  that  was  previously 
developed  to  provide  information  on  the  activities  of  dismounted  soldiers  for  use  by  desk  officers 
preparing  SORs  and  by  contractors  developing  equipment.  The  information  in  the  Soldier’s  Day 
database  is  structured  by  Organization,  Tasks  and  Equipment,  which  may  not  be  the  most 
effective  structure  for  the  new  SOR  templates.  It  was  determined  that  a  worked  example  was 
required  to  explore  how  the  new  SOR  templates  may  dictate  the  organization  and  types  of  HSI 
information  needed  for  future  acquisition  projects. 

HSI  issues  related  to  Armoured  Fighting  Vehicles  (AFVs)  were  identified  as  a  possible  worked 
example  for  such  a  study.  According  to  DLR  3-2-2,  “Current  AFVs  lack  valid  HF  requirements 
specifications,...  battlefield  days  for  Operations  Other  than  War  (OOTW)  must  be  defined,... 
another  weakness  in  AFV  HF  engineering  has  been  the  availability  of  valid  anthropomorphic  data 
[which  are  now  available  through  Clothe  The  Soldier], . . .  mounted  and  dismounted  clothing  and 
equipment  requirements  must  be  harmonized  in  order  to  provide  soldiers  (such  as  section 
commanders)  with  personal  clothing  and  equipment  for  both  mounted  and  dismounted  operations. 
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. . .  mounted  soldier  performance  can  therefore  be  improved,  and  mounted/  dismounted 
requirements  harmonized,  by  the  accurate  definition  of  AFV  HF  requirements.” 

DLR  3  staff  proposed  an  AFV  HSI  initiative  to  maximize  mounted  soldier  performance  by: 

•  Improving  the  current  and  future  vehicle  environments; 

•  Improving  personal  equipment  and  clothing; 

•  Modifying  mounted  tactics,  techniques  and  procedures  (TTPs); 

•  Improving  current  recruiting,  selection  and  training  methods;  and 

•  Enhancing  the  soldier’s  physiological  state  through  food  and  drugs. 

The  aim  of  this  project  was  to  use  the  DLR-3  AFV  HSI  initiative  as  a  worked  example  to  explore 
the  kinds  of  information  required,  and  the  information  which  is  currently  available,  to  complete 
the  HSI  sections  of  the  new  DND  SOR  templates. 

1 .2  Objective 

The  objectives  of  this  project  were: 

1.  to  develop  a  structure  for  the  HSI  requirements  for  AFVs  that  matches  the  structure  of  the 
new  DND  SOR  templates; 

2.  to  explore  methods  to  make  this  HSI  information  available  to  members  of  AFV  project 
teams  using  electronic  means,  possibly  including  the  use  of  a  modified  version  of 
Soldier’s  Day. 

1.3  Deliverables 

The  deliverables  from  this  project  included: 

•  A  report  on  how  the  HSI  requirements  in  the  new  SOR  templates  can  be  addressed  and 
how  the  AFV  HSI  information  could  be  distributed  as  part  of  a  www  site  using  AFV  HSI 
as  a  worked  example. 

Additional  project  work  completed  in  parallel  generated  a  companion  report  that  provides: 

•  An  annotated  bibliography  of  available  information  relevant  to  HSI  requirements  for 
future  AFV  related  SORs,  organized  to  match  the  SOR  templates. 

•  A  report  on  what  AFV  HSI  information  is  known,  what  information  needs  to  be 
collected,  how  much  of  it  requires  R&D,  what  R&D  needs  to  be  completed,  and  the 
outline  of  an  AFV  HSI  R&D  program  to  generate  the  requirements  for  the  future. 
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2  Method 


This  section  outlines  the  method  followed  in  this  project.  The  primary  tasks  completed  by  the 
project  team  are  reviewed  in  the  following  sub-sections. 

2.1  Start  Up  Meetings 

The  project  was  initiated  with  a  series  of  start  up  meetings.  These  began  with  the  Humansystems 
project  team  meeting  to  review  the  contract  documents  and  conceptualizing  their  approach  to  the 
analysis.  Two  start  up  meetings  followed  in  Ottawa,  first  with  the  DRDB  scientific  authority,  and 
a  second  with  the  project  sponsor  in  DLR  3. 

In  combination,  this  series  of  meetings  refined  the  scope  of  the  project,  assisted  in  the 
development  of  the  method  for  the  project,  and  identified  information  sources  that  the  project 
team  should  review. 

The  meeting  with  DLR  3  personnel  was  also  used  to  identify  the  types  of  project  for  which  SORs 
may  have  to  be  developed  over  the  next  5  to  10  years.  The  identification  of  these  projects  was 
important  to  guide  the  analysis  of  future  HSI  requirements. 

2.2  Develop  Project  Review  Framework 

The  project  team  met  on  a  number  of  occasions  to  develop  the  framework  for  analysis  of  HSI 
requirements  during  the  project.  This  process  started  with  a  review  of  the  new  SOR  in  the 
Guidelines  for  the  Preparation  of  a  Statement  of  Operational  Requirements  (DBCM  1998)  to 
identify  SOR  sections  with  HSI  components 

This  review  generated  a  structure  for  classifying  literature  in  relation  to  future  AFV  SORs.  This 
structure  was  felt  to  be  generic  for  all  projects,  with  some  minor  tailoring  to  meet  the  specific 
needs  of  future  Armour  Systems  projects. 

2.3  Obtain  and  Review  Available  Literature 

The  project  team  obtained  any  immediately  available  literature  related  to  HSI  for  AFV  SORs. 

This  literature  came  from  DRDB  Laboratories,  DLR  3  filing  cabinets,  and  recent  AFV  related 
projects  completed  by  the  Humansystems  team.  Some  literature  was  also  obtained  from  related 
projects  (eg:  Clothe  the  Soldier)  which  was  immediately  available  to  the  project  team. 

It  was  decided  to  first  review  the  available  literature  and  then  determine  if  there  were  sufficient 
project  resources  to  extend  the  search  further.  In  the  end,  an  enhanced  literature  search  was  not 
feasible  due  to  the  volume  of  initial  materials  obtained. 


2.4  Organize  and  Prioritize  Literature  by  SOR  Section 

The  literature  reviewed  was  annotated  and  categorized  according  to  the  SOR  framework 
developed.  All  reviews  and  categorizations  were  entered  into  an  Endnote  (bibliographic 
software)  database.  The  annotation  of  each  article  included  a  ranking  of  the  relevance  of  the 
paper  to  future  DLR  3  acquisition  projects. 
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2.5  Develop  HSI  Information  Distribution  Concepts 

Once  the  HSI  framework  for  the  new  SOR  template  was  established,  and  some  of  the  AFV 
related  literature  was  reviewed,  the  project  team  started  to  analyze  how  HSI  related  information 
could  be  effectively  distributed  to  interested  parties  using  electronic  means. 

This  process  began  with  a  review  of  electronic  distribution  requirements  identified  in  previous 
projects,  including  the  SOR  Spec  Maker  projects  (Greenley,  Tack,  Angel,  and  Webb  1998; 
Greenley,  1999a,  Greenley,  1999b)  and  the  Human  Factors  Engineering  Tools  project  (Greenley, 
1999c). 

Additional  material  reviewed  included  recent  descriptions  of  the  DRDB  HSI  Web  Site  (Vallerand 
1999),  and  the  latest  description  of  the  Soldier’s  Day  database  (Kumagai,  1999). 

The  user  requirements  were  compared  against  the  capabilities  of  the  HSI  Web  Site  and  the 
Soldier’s  Day  database  to  determine  what  the  options  might  be  for  electronic  distribution. 

2.6  Identify  Gaps  in  Existing  Knowledge 

The  review  of  AFV  related  literature  against  the  SOR  categories  resulted  in  the  identification  of 
areas  where  future  Armour  Systems  SORs  would  have  sufficient  requirements,  and  areas  where 
there  are  currently  gaps  in  the  existing  knowledge  about  HSI  requirements.  These  gaps  were 
identified  and  briefly  described. 

2.7  Develop  Future  R&D  Program 

The  gaps  in  the  existing  HSI  requirements  literature  were  mapped  against  R&D  activities  that 
could  be  completed  to  produce  the  missing  requirements,  which  were  then  organized  into  a  series 
of  R&D  projects  to  form  the  description  for  an  AFV  HSI  R&D  Program.  Where  possible,  cost 
estimates  were  developed  for  elements  of  this  HSI  R&D  Program  as  a  tool  for  future  planning. 

2.8  Develop  Final  Reports  and  Presentation 

The  outputs  of  this  work  were  integrated  into  two  reports  and  one  presentation.  The  two  reports 
included: 

1 .  Guidance  for  Addressing  the  Human  Systems  Integration  Content  of  DND  SORs 
(this  report) 

2.  A  Review  of  Human  Systems  Integration  Material  Available  for  Armour  Systems  SORs  and 
a  Plan  for  Future  HSI  R&D. 

The  results  of  both  reports  were  integrated  into  one  presentation  that  was  delivered  in  Ottawa  to 
the  DRDB,  DLR  3,  and  DLR  10  communities. 
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3  Results 


This  section  of  the  report  contains  the  results  of  the  project  that  relate  to  addressing  HSI 
components  of  the  SOR  and  electronic  mechanisms  for  distributing  HSI  information  amongst 
project  teams. 


3.1  SOR  Structure 

The  “Guidelines  on  the  Preparation  of  a  Statement  of  Operational  Requirements”  (DBCM  1998) 
outlines  an  SOR  with  the  structure  illustrated  in  Figure  1 .  This  structure  results  in  a  SOR  with 
two  core  themes;  (i)  Systems  Effectiveness,  and  (ii)  Human  System  Integration.  The  SOR 
contents  result  in  solid  traceability  from  the  Defence  Planning  Guidance  scenarios  down  to  the 
performance  requirements  of  an  individual  system. 


1.  Introduction 

1.1.  Aim 

1 .2.  Background  -  Origin 
1  3.  Deficiency 

1 .4  Project  Constraints 
1 .5.  Current  Situation 

1  6.  Related  Projects 

2.  System  Operation 

2.1 .  Missions  and  Scenarios 

2.2  Environment 

2.3  Threats 

2.4.  Concept  of  Operations 

2.5.  Concept  of  Support 

2  6  Key  Roles 
2  7.  Key  Tasks 

2.8.  User  Characteristics 

3.  Design  and  Concept  Guidance 

4.  System  Effectiveness  Requirements 

4.1  General 

4.2.  Operability 

4.2  1  Performance  Capability 

4.2  2  Crew  Station  and  Interface  Design 

4.2  3  User  Acceptance 
4  3  Survivability 

4  4.  Maintainability 

4.4  1 .  Maintenance  Task  Performance 

4.4.2  Crew  Station  and  Interface  Design 
4  4.3.  User  Acceptance 


4.5  Availability 
4  6.  Reliability 

4  7.  Environmental  Sustainability 

4.8  Safety  and  Health 

4  9  Delivery  Requirements 

4.9  1 .  Quantity 
4  9.2.  Quality 
4  9.3  Location 

5.  Sub-System  Effectiveness  Requirements 

6.  Performance  Measures 

6  1 .  System  Level  Measures 

6  2.  Sub-System  Level  Measures 

7.  Personnel  And  Training  Requirements 

7  1  Personnel  -  Staffing 
7.1.1.  Operational  Staff 
7  1.2.  Maintenance  Staff 

7.2.  Training 

7  2  1.  Operational  Training 

7.2.2.  Maintenance  Training 

7.2.3.  Simulation 

8.  Scheduling  Requirements 

9.  Requirements  Table 


Figure  1:  SOR  Structure 


Humansysfe/ns  Incorporated 


Annex  B  Soldier’s  Day  Concept 


Page  5 


3.1.1  Human  Systems  Integration  in  the  new  SOR  Framework 

Human  Systems  Integration  is  defined  as: 

The  technical  process  of  integrating  the  areas  of: 

1.  human  engineering, 

2.  manpower, 

3.  personnel, 

4.  training, 

5.  systems  safety,  and 

6.  health  hazards, 

with  a  materiel  system  to  ensure  safe,  effective  operability  and  supportabihty. 

This  concept  is  highlighted  in  the  new  SOR  guidelines  along  with  the  concept  of  Systems 
Effectiveness,  both  as  guiding  principles  behind  the  acquisition  process.  As  a  result,  there  are  a 
number  of  the  SOR  sections  and  sub-sections  that  contain  HSI  requirements.  These  sections  are 
not  necessarily  exclusive  to  the  HSI  domain,  however,  HSI  requirements  are  expected  to  be 
included  in  the  resulting  content.  HSI  related  sections  and  sub-sections  are  highlighted  and 
bolded  in  Figure  2. 


1  Introduction 

4.5.  Availability 

1  I.Aim 

4.6.  Reliability 

1  2.  Background  -  Origin 

4.7  Environmental  Sustainability 

1.3.  Deficiency 

4.8.  Safety  and  Health 

1 .4.  Project  Constraints 

4.9  Delivery  Requirements 

1 .5  Current  Situation 

4.9.1.  Quantity 

1  6.  Related  Projects 

4.9  2  Quality 

2  System  Operation 

4  9  3  Location 

2.1.  Missions  and  Scenarios 

5  Sub-System  Effectiveness  Requirements 

2.2  Environment 

6.  Performance  Measures 

2.3.  Threats 

6. 1 .  System  Level  Measures 

2.4.  Concept  of  Operations 

6.2.  Sub-System  Level  Measures 

2.5.  Concept  of  Support 

7.  Personnel  And  Training  Requirements 

2.6.  Key  Roles 

7.1.  Personnel  -  Staffing 

2.7.  Key  Tasks 

7.1.1.  Operational  Staff 

2.8.  User  Characteristics 

7.1.2.  Maintenance  Staff 

3  Design  and  Concept  Guidance 

7.2.  Training 

4  System  Effectiveness  Requirements 

7.2.1.  Operational  Training 

4.1  General 

7.2.2.  Maintenance  Training 

4.2.  Operability 

7.2.3.  Simulation 

4.2.1.  Performance  Capability 

8  Scheduling  Requirements 

4.2.2.  Crew  Station  and  Interface  Design 

9  Requirements  Table 

4.2.3.  User  Acceptance 

4.3.  Survivability 

4.4.  Maintainability 

4.4.1.  Maintenance  Task  Performance  1 

4.4.2.  Crew  Station  and  Interface  Design 

4.4.3.  User  Acceptance 

Figure  2:  SOR  Structure  with  Highlighting  Sections  with  HSI  Related  Content 
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The  following  points  outline  the  type  of  HSI  requirements  that  are  typically  defined  in  the 

highlighted  sections  of  Figure  2: 

•  Deficiency.  This  section  will  often  contain  human  centric  deficiencies  related  to  concerns 
with  current  system  or  task  performance,  training  systems,  staffing,  or  personnel  safety. 

•  Missions  and  Scenarios.  This  section  will  contain  a  description  of  the  missions  and  scenarios 
that  the  system  will  operate  under.  These  scenario  descriptions  will  define  the  operational 
environment,  own  force  composition,  threat  force  composition,  typical  deployment  patterns, 
and  scenario  event  sequences.  The  main  body  of  the  SOR  will  often  contain  only  a  summary 
of  these  scenarios,  with  more  complete  analysis  in  an  Annex  or  a  referenced  report.  These 
missions  and  scenarios  are  required  as  the  basis  for  the  subsequent  analysis  of  future 
requirements  for  the  system  and  provide  a  traceable  link  back  to  the  Defence  Planning 
Guidance  scenarios  for  the  entire  Canadian  Forces. 

•  Concept  of  Operations.  This  section  will  summarize  the  future  concept  under  which  the 
system  will  operate.  This  section  will  outline  own  force  composition,  deployment,  and  the 
general  use  of  the  system  or  sub-system  in  operations. 

•  Concept  of  Support.  This  section  will  define  the  concept  for  the  maintenance  and  support  of 
the  future  system.  Of  importance  to  HSI  analysis  is  the  relative  role  of  military  and 
commercial  support  in  the  future  concept,  and  task  performance  concepts  such  as  component 
repair  versus  component  replacement. 

•  Kev  Roles.  This  section  identifies  and  briefly  describes  the  key  positions  related  to 
operations  and  support  as  they  in  turn  relate  to  the  Concepts  of  Operation  and  Support. 

•  Kev  Tasks.  This  section  identifies  and  briefly  describes  the  key  tasks  to  be  performed  by  the 
personnel  filling  the  key  roles  for  both  operation  and  support  of  the  future  system,  using  the 
new  Concept  of  Operation  and  Concept  of  Support. 

•  User  Characteristics.  This  section  will  identify  the  range  of  characteristics  of  the  entire  user 
community,  not  necessarily  just  those  of  the  key  users  listed  under  Key  Roles.  These 
characteristics  will  include  anthropometric  ranges,  gender,  medical  characteristics  (vision, 
hearing),  task  skill  sets,  and  qualification  standards,  among  others. 

•  Operability  -  Performance  Characteristics.  This  section  of  the  SOR  will  contain  a  range  of 
key  performance  characteristics  many  of  which  may  be  technical.  However,  the  key  user  task 
performance  requirements  of  the  future  systems  will  also  be  defined  here  as  they  relate  to  the 
key  tasks  to  be  performed  within  the  identified  scenarios,  using  the  previously  defined 
concept  of  operations. 

•  Operability  -  Crew  Station  and  Interface  Design.  This  section  will  identify  key  user  centered 
requirements  related  to  the  layout  of  future  crew  stations  or  interfaces.  These  requirements 
will  identify  any  critical  layout  issues  or  task  performance  requirements  to  ensure  that  each  of 
the  key  roles  will  be  able  to  perform  their  key  tasks  within  the  scenarios  under  the  Concepts 
of  Operation  and  Support  identified.  Often  these  requirements  will  list  the  critical  equipment, 
displays,  or  controls  that  will  need  to  be  accessible  by  each  class  of  user  from  their  crew 
station. 

•  Operability  -  User  Acceptance.  This  section  of  the  SOR  will  identify  requirements  regarding 
how  user  acceptance  will  be  evaluated  on  the  project,  any  baseline  criteria  that  must  be  met, 
and  the  criteria  for  meeting  user  acceptance  thresholds  for  the  project.  In  some  cases  these 
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criteria  may  be  linked  to  baseline  surveys  of  existing  products  using  ACCESS  measures 
(Greenley  1999c)  or  comparable  systems. 

•  Survivability.  This  section  of  the  SOR  will  identify  requirements  for  system  survivability 
against  the  threats  identified  earlier  in  the  SOR,  however,  from  an  HSI  perspective  it  will  also 
define  requirements  related  to  the  survivability  of  the  human  while  operating  the  future 
system.  These  requirements  will  often  relate  to  personnel  protection  related  to  threats,  with 
general  safety  and  health  hazard  requirements  identified  later  in  the  SOR. 

•  Maintainability  -  Maintenance  Task  Performance.  This  section  will  identify  the  primary 
maintenance  task  performance  requirements  of  the  future  system  for  tasks  to  be  performed 
within  the  scenarios,  using  the  previously  defined  Concept  of  Support. 

•  Maintainability  -  Crew  Station  and  Interface  Design.  This  section  of  the  SOR  will  identify 
any  crew  station  or  interface  layout  requirements  associated  with  maintenance  task 
performance.  These  may  relate  to  maintenance  specific  displays  or  controls,  or  general 
access/egress  to/from  key  equipment,  as  examples. 

•  Maintainability  -  User  Acceptance.  Any  requirements  related  to  future  measurement  of 
maintainer  acceptance  of  the  system  will  be  included  in  this  SOR  section.  These 
requirements  may  often  be  similar  to  the  User  Acceptance  requirements  in  the  operations 
section  of  the  SOR. 

•  Availability.  This  section  will  identify  system  availability  requirements,  which  should 
always  include  the  human  component  of  the  availability  equation.  From  an  HSI  perspective 
these  requirements  will  often  relate  to  sustained  operations  and  the  required  availability  of  the 
entire  system  including  its  human  operators.  These  requirements  will  also  include  skill 
fading  requirements  (the  duration  that  a  trained  user  will  retain  their  skill  level)  related  to 
training  needs,  and  associated  training  frequency. 

•  Reliability.  This  SOR  section  will  include  requirements  related  to  overall  system  reliability 
including  the  human  error  component  in  system. 

•  Safety  and  Health.  This  section  of  the  SOR  will  include  requirements  related  to  preserving 
the  safety  and  health  of  the  future  operators  and  maintainers  within  the  physical  and  threat 
environments  defined  in  the  scenarios. 

•  Performance  Measures.  These  requirements  will  include  a  range  of  system  and  task  level 
performance  measures  to  be  used  throughout  procurement  to  evaluate  the  system.  Many  of 
these  measures  will  require  humans  to  be  operating  the  system  in  order  to  measure  them,  and 
will  therefore  require  HSI  based  analysis  to  establish  and  validate  the  measures  in  addition  to 
HSI  methods  to  collect  performance  data  during  future  system  user  trials. 

•  Personnel-Staffing.  This  SOR  section  will  include  the  staffing  requirements  based  on  the 
project  scenarios,  the  Concept  of  Operations,  and  the  Concept  of  Support.  Alternatively, 
these  HSI  requirements  may  state  limits  on  the  staffing  impact  of  the  future  system  (eg:  the 
new  system  shall  not  alter  staffing  requirements). 

•  Training  -  Operational  and  Maintenance.  These  requirements  include  the  HSI  requirements 
related  to  the  training  systems  for  both  operators  and  maintainers,  and  will  include 
requirements  for  both  courses  and  facilities. 

•  Simulation.  This  section  will  include  requirements  for  simulation  in  the  training  plan.  This 
will  include  simulation  based  facilities  for  training  key  operational  and  maintenance  tasks. 
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3.1.2  Evaluation  of  HSI  Related  Sections  in  SOR  Template 

This  project  has  allowed  the  team  to  review  the  content  of  the  new  SOR  and  the  associated 
guidelines  from  an  HSI  perspective.  In  order  for  users  of  the  SOR  template  to  be  able  to 
effectively  develop  and  document  HSI  requirements  it  is  important  that  the  structure  of  the 
document  allow  for  all  domains  of  HSI  to  be  addressed  effectively.  It  is  also  important  that  the 
HSI  related  sections  do  not  create  overlap  or  confusion  as  to  where  different  requirements  should 
be  entered. 

In  general  the  SOR  framework  and  the  new  guidelines  cater  to  and  accommodate  the  full  range  of 
HSI  issues,  however,  it  would  take  a  user  with  some  HSI  experience  to  be  able  to  identify, 
analyze,  and  document  all  of  the  relevant  HSI  requirements  into  the  appropriate  sections.  The 
existing  guidelines  provide  a  very  high  level  of  prompting  of  the  issues  that  should  be  considered 
in  the  various  sections,  however,  a  further  level  of  prompting  is  required  for  the  average  project 
staff  member  to  realize  the  extent  of  the  HSI  issues  involved.  An  example  of  the  prompting  level 
required  can  be  found  in  the  USA  MANPRINT  program  where  a  list  of  “typical  questions”  are 
identified  for  each  of  the  domains  of  HSI. 

Particularly  lacking  in  the  current  SOR  guidelines  is  a  complete  definition  of  the  Health  Hazards 
Assessment  (HHA)  area.  Again  the  system  employed  in  the  USA,  and  a  component  of  their 
MANPRINT  system,  provides  a  systematic  structure  for  the  HHA  domain.  This  American  HHA 
taxonomy  was  used  during  the  current  project  as  the  basis  for  the  review  of  HSI  literature  for 
AFVs  and  was  found  to  be  quite  effective.  It  would  be  of  benefit  for  the  Canadian  system  to 
adopt  a  similar  framework  to  guide  the  requirements  development  process  in  this  area 

There  are  two  components  of  the  SOR  that  appear  to  overlap  and  have  the  potential  to  lead  to 
confusion  for  the  author.  The  first  relates  to  the  documentation  of  requirements  related  to  human 
error,  while  the  other  relates  to  human  performance  requirements. 

Human  error  requirements  are  identified  through  human  factors  analysis  and  safety  analysis,  and 
could  be  documented  in  the  SOR  in  a  number  of  areas.  Two  primary  areas  are  the  section  on 
Reliability,  which  includes  the  reliability  of  the  human  operator  and  any  errors  they  may  make 
that  decreases  overall  system  reliability;  and  the  section  on  Safety  which  includes  requirements  to 
ensure  that  human  operators  or  maintainers  don’t  make  errors  causing  harm  to  themselves. 

Human  error  can  also  be  interpreted  at  times  to  be  a  component  of  Availability.  At  the  moment  it 
appears  that  human  error  issues  are  best  documented  in  the  Reliability  section  and  the  SOR 
guidelines  could  be  enhanced  to  make  this  clearer. 

Human  task  performance  requirements  are  to  be  documented  in  the  SOR  in  the  section  on 
Operability  -  Performance  Characteristics.  This  is  clear  to  the  SOR  author,  however,  the  later 
section  on  Performance  Measures  naturally  overlaps  with  the  performance  requirement  section 
which  can  lead  to  confusion.  For  example,  a  Performance  Characteristic  might  be  that  an  AFV 
crew  be  able  to  engage  and  destroy  a  target  of  type  “x”  at  2000m  within  20  seconds.  This  could 
also  easily  be  an  entry  in  the  Performance  Measure  section.  It  seems  natural  that  the  Performance 
Measure  section  would  “roll  up”  or  summarize  the  key  performance  requirements  of  the  future 
system,  including  key  human  task  performance  measures.  However,  the  guidelines  on  SOR 
development  are  not  clear  as  to  whether  it  is  expected  that  earlier  requirements  can  be  repeated  in 
the  Performance  Measures  section  or  not,  and  if  so  what  the  subsequent  impact  on  numbering  and 
tracking  should  be. 
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3.1 .3  Human  Systems  Integration  in  the  SOR  Development  Process 

The  Guidance  on  the  Preparation  of  a  Statement  of  Operational  Requirements  (DBCM  1998)  also 
includes  a  recommended  basic  process  for  the  development  of  new  requirements.  This  process 
includes  a  series  of  steps,  listed  in  Figure  3.  Many  of  these  steps  include  analyses  or  evaluations 
that  centre  on  the  human  operators  or  maintainers  of  the  future  system,  and  their  requirements 
These  more  human  centric  elements  of  the  sequence,  highlighted  in  Figure  3,  can  utilize  HSI 
methods,  tools,  and  techniques  to  determine  and  validate  user  requirements. 


• 

Identify  the  Project 

# 

Identify  Resources 

• 

Analyze  Missions  and  Scenarios 

• 

Analyze  the  Concept  of  Operations  (CONOPS) 

• 

Analyze  the  Concept  of  Support  (CONSUP) 

• 

Define  and  Describe  the  Key  Roles  and  Tasks 

• 

Conduct  Task  Analysis 

• 

Develop  Draft  SOR 

fl 

Validate  Draft  SOR 

1 

Conduct  Studies  and  Trials 

r 

1 

• 

Develop  Final  SOR  \  j 

• 

Validate  Final  SOR 

HU 

• 

¥ 

Obtain  Approvals  and  Deliver  Signed  SOR 

Figure  3:  Recommended  SOR  Development  Process  with  HSI  Related  Analyses  Highlighted 

At  the  core  of  the  HSI  component  of  this  SOR  development  process  is  a  veiy  user  centred 
sequence  with  many  analyses  linked  to  one  another.  The  analysis  begins  with  scenario  definition 
and  leads  to  analysis  of  key  roles  and  tasks,  after  which  the  described  tasks  are  analyzed  for 
future  requirements  related  to  performance,  displays,  controls,  safety,  training,  safety,  etc..  HSI 
techniques  are  often  then  used  to  validate  draft  requirements  with  the  user  community  through 
questionnaires  or  focus  groups  using  mockups  or  prototypes.  When  more  in  depth  investigation 
is  still  required  to  detail  the  requirements  for  a  future  system,  studies  are  often  conducted  that 
include  performance  modeling,  field  trials,  or  human-in-the  loop  simulation.  The  sequence  is 
completed  with  final  validation  of  the  requirements  set  through  group  meetings  or  further  studies 
and  trials. 
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3.2  How  to  Address  Human  Systems  Integration  in  the  new  SOR 

This  section  of  the  report  attempts  to  provide  guidance  on  how  to  address  the  foregoing  HSI 
requirements,  using  a  future  Armour  System  SOR  as  the  worked  example. 

Throughout  the  requirements  development  process,  the  basic  method  to  address  HSI  requirements 
of  the  SOR  consists  of  three  key  activity  streams: 

1.  Deficiency  Analysis.  Systematically  analyze  the  operational  deficiencies  that  the  project 
must  address.  This  is  an  activity  area  in  itself,  but  is  also  a  key  component  of  the  next 
two  activity  areas. 

2.  Literature  Review.  Conduct  a  review  of  the  available  literature  to  identify  HSI 
requirements  in  the  areas  indicated  by  the  SOR. 

3.  Scenario  Based  Analysis.  Follow  the  analysis  sequence  recommended  in  the  new  SOR 
guidelines  (see  Section  3.1.2  of  this  report)  working  from  scenarios,  to  operations  and 
support  concepts,  to  analysis  of  functions  and  tasks,  to  detailed  task  analysis,  to  the 
development  of  requirements  and  performance  measures.  As  previously  discussed,  this 
sequence  will  be  initiated  with  a  solid  analysis  of  the  deficiencies  of  existing  systems 
within  this  scenario  context,  and  may  involve  additional  studies  or  evaluations  with 
future  users  throughout. 

The  success  of  this  analysis  sequence  depends  on  a  number  of  factors,  including: 

•  Available  Literature.  Existing  literature  needs  to  be  available  in  a  readily  accessible 
format. 

•  Integrated  HSI  Analysis  Process.  An  integrated  analysis  process  is  required,  that  allows 
the  requirements  for  each  of  the  HSI  domains  to  be  determined,  tracked,  and  evaluated. 

•  Integrated  HSI  Tools  and  Techniques.  Tools  and  techniques  are  required  that  allow  a 
range  of  HSI  requirements  to  be  determined  or  evaluated. 

Each  of  these  three  factors  is  addressed  further  in  the  following  sub-sections. 

3.2.1  Available  Literature 

Ensuring  that  the  relevant  literature  is  available  for  future  SORs  is  dependent  on  proactive 
initiative  within  each  Directorate  or  cell  in  DND.  Using  Armour  Systems  as  an  example,  this 
project  identified  four  types  of  SORs  that  were  likely  to  be  developed  over  the  next  5  to  10  years 
and  then  reviewed  the  available  literature  for  HSI  related  requirements  that  may  be  relevant  to 
those  SORs,  ranking  the  material  by  the  likely  level  of  HSI  relevance.  During  this  project  over 
500  papers  were  identified  and  briefly  reviewed  for  HSI  related  Armour  Systems  requirements, 
resulting  in  over  1 00  papers  being  classified  as  directly  relevant  to  future  SORs  for  DLR  3  or 
DLR  10. 

The  low  tech  way  of  organizing  this  information  is  using  filing  cabinets  and  binders,  indexed 
according  to  the  types  of  SOR  (eg:  vehicle,  clothing  systems)  that  it  may  pertain  to,  and  even  the 
SOR  section  that  it  may  pertain  to  (eg:  Deficiencies,  Performance  Measures).  This  method  is 
difficult  in  the  current  DND  environment  due  to  the  restrictions  on  both  storage  space  and  the 
number  of  filing  cabinets. 
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A  more  advanced,  and  more  effective  method,  of  distributing  and  sharing  this  literature  would  be 
to  organize  it  and  make  it  available  in  an  electronic  form.  This  issue  is  addressed  further  in 
Section  4.0  of  this  report  as  it  was  requested  that  particular  attention  be  paid  to  it  throughout  this 
project. 

The  method  selected  to  organize  reviewed  literature  must  also  accommodate  efficient 
organization  of  the  analyzed  deficiencies  for  the  project.  These  deficiencies  may  have  been 
identified  through  a  literature  review,  but  will  also  include  inputs  from  communications 
throughout  DND,  the  UCR  system,  or  more  systematic  analysis  such  as  the  ACCESS  method 
which  was  developed  to  systematically  document  deficiencies  and  subsequent  requirements  for 
future  systems  (see  Greenley  1999c). 

3.2.2  Integrated  HSI  Analysis  Process 

The  development,  validation,  and  tracking  of  HSI  requirements  is  best  facilitated  through  an 
integrated  analysis  sequence.  An  HSI  Process  of  this  nature  is  currently  required  in  Canada, 
especially  one  that  integrates  with  the  Defence  Management  System  and  the  DND  Materiel 
Acquisition  and  Support  (MA&S)  process.  It  is  expected  that  such  a  process  will  be  generated 
through  the  DRDB  over  the  next  several  years,  assuming  that  current  levels  of  support  for  an  HSI 
program  are  maintained. 

An  example  of  an  integrated  HSI  Process  is  illustrated  in  Figure  4.  This  figure  demonstrates  that 
many  of  the  analyses  in  a  typical  HSI  analysis  sequence  can  be  used  to  generate  and  validate 
requirements  in  multiple  HSI  domains.  This  type  of  sequence  is  critical  to  ensure  that  as  an 
analysis  is  updated  throughout  the  acquisition  cycle,  the  impact  on  requirements  in  each  HSI 
domain  is  simultaneously  realized,  tracked,  and  evaluated. 

This  type  of  integrated  process  is  absolutely  essential  to  facilitate  tradeoff  analysis,  which  is  one 
of  the  most  complex  aspects  of  an  HSI  program.  An  example  of  tradeoff  analysis  would  be  when 
the  technology  of  a  new  system  impacts  the  relative  roles  of  crew  members,  which  then  impacts 
training  requirements,  and  potentially  even  staffing  or  recruitment  requirements.  If  there  are 
limits  on  the  permitted  personnel  impact  or  training  requirements  for  the  future  system  then  trade 
offs  must  be  made  within  the  operational  or  support  concepts  to  utilize  the  technology  in  a 
different  fashion. 
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Figure  4:  Example  HSI  Process  Integrating  all  of  the  HSI  Domains 
(adapted  from  Greenley  1999c) 


As  indicated  in  Figure  5,  the  HSI  Process  is  not  completed  once,  but  is  repeated  at  least  three 
times  throughout  the  acquisition  and  development  cycle  to  define  requirements,  detail 
performance  specifications,  generate  designs,  and  evaluate  final  systems.  Therefore,  the 
establishment  and  maintenance  of  an  integrated  process  is  essential  to  provide  efficiency  and 
traceability  throughout  any  one  project. 
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Figure  5:  Illustration  of  HSI  Process  Repeating  Several  Times  Throughout  a  Project 

(from  Greenley  1999c) 


3.2.3  Integrated  HSI  Tools  and  Techniques 

At  the  core  of  an  integrated  analysis  process  are  tools  and  techniques  that  result  in  common  data 
being  shared  by  each  of  the  HSI  domains.  When  tools  developed  and  used  that  facilitate  this 
sharing  of  data,  the  analysts  are  able  to  generate,  validate,  and  track  requirements  in  several  HSI 
domains  each  time  a  core  analysis  is  repeated  or  updated.  For  the  purposes  of  this  report,  the 
critical  sets  of  HSI  tools  or  techniques  can  be  organized  into  three  groups: 

1 .  Operational  Experience  and  Lessons  Learned 

2.  Scenario  Analysis 

3.  Workspaces  and  Human  -  Machine  Interfaces 

Figure  6  maps  these  three  groups  of  tools  against  the  illustrative  HSI  process  to  indicate  the  tool 
coverage  and  the  inter-linking  of  the  analysis  throughout.  Figure  7  illustrates  how  Operating 
Experience  (Literature  and  Deficiency  Analysis),  Scenario  Analysis,  and  Workspaces  integrate 
mto  the  SOR  development  process. 
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Figure  6:  Three  Groups  of  HSI  Analysis  Techniques  vs  the  HSI  Analysis  Process 
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3. 2.3.1  Operational  Experience  and  Lessons  Learned 

Tools  that  analyze  and  track  operational  experience  and  lessons  learned  are  used  by  each 
of  the  HSI  domains.  In  the  case  of  Human  Factors,  these  tools  identify  task  performance 
concerns,  or  component  integration  concerns.  For  Training  these  tools  identify  concerns 
with  training  from  past  versions  or  related  in-service  systems.  For  Personnel  &  Staffing 
these  tools  generate  concerns  with  staffing  from  past  or  related  systems.  For  Safety  & 
Health  Hazards  accident/incident  data  from  previous  systems  are  organized  or  tracked  by 
experience  or  lessons  learned  based  tools. 

The  lower  tech  tools  to  process  this  class  of  requirement  includes  literature  reviews,  or 
interviews. 

The  higher  tech  tools  in  this  category  include  the  ACCESS  set  of  tools,  or  enhanced 
versions  of  ACCESS  linked  with  electronic  distribution  mechanisms  such  as  the  Soldier’s 
Day  database.  With  these  tools  different  Directorates  are  able  to  systematically  analyze 
and  track  operator  or  maintainer  concerns  with  systems  and  then  organize  and  distribute 
the  results  in  a  format  that  all  classes  or  geographically  distributed  users  can  take 
advantage  of 

3.2.3.2  Scenarios  (Descriptions,  Functions,  Tasks,  Organization,  Users) 

Scenario  based  analysis  consists  of  describing  future  operational  and  maintenance 
scenarios,  identifying  and  analyzing  the  allocation  of  functions  to  be  performed,  and 
analyzing  the  tasks  allocated  to  the  human  operators  or  maintainers.  This  analysis  must 
be  complimented  by  parallel  and  linked  analysis  of  the  organizational  structure  of  the 
operational  and  support  concepts,  in  addition  to  an  assessment  of  the  characteristics  of  the 
user  populations. 

Scenario  based  analysis  tools  are  employed  by  the  Human  Factors  domain  to  conduct 
function  allocation,  to  generate  system  and  interface  requirements,  and  to  develop 
performance  measures.  The  Training  domain  uses  these  tools  to  determine  and  track 
knowledge/skill/ability  requirements  and  future  training  measures.  The  Personnel 
domain  identifies  preliminary  personnel  and  staffing  requirements  throughout  the 
acquisition  cycle  using  these  tools,  while  the  Safety  and  Health  Hazards  community  uses 
the  same  types  of  analysis  to  identify  and  design  for  safety  and  hazard 
concems/requirements. 

The  lower  tech  version  of  hierarchical  scenario  based  analysis  of  systems  involves 
different  flow  charting  techniques  to  map  out  function  flows,  decision-action  sequences, 
or  the  task  flow  between  system  components  using  techniques  such  as  Operational 
Sequence  Diagrams.  Each  time  these  analyses  are  updated,  the  resulting  impact  on  each 
of  the  HSI  domains  is  then  tracked,  usually  in  some  tabular  format. 

The  higher  tech  tools  to  conduct  scenario  based  analysis,  and  then  predict  the  impact  of  a 
future  system  design  on  each  of  the  HSI  domain  areas,  mvolves  the  use  of  Task  Network 
Modeling.  The  DND  tool  of  choice  for  this  type  of  modeling  is  the  Integrated 
Performance  and  Modeling  Environment  (IPME)  supported  through  R&D  at  DCIEM. 
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In  each  case,  re-usable  models  of  the  operation  and  support  scenarios  are  decomposed 
into  the  associated  functions  and  tasks,  and  kept  up  to  date  throughout  the  acquisition  and 
support  cycle. 

3. 2.3. 3  Workspaces  and  Interfaces 

Workspace  and  interface  design  tools  are  used  to  create  mockups,  prototypes,  or 
simulations  of  crew  stations  and  human-machine  interfaces.  These  representations  are 
then  used  as  the  basis  for  analysis  of  requirements  or  specifications  in  each  of  the  HSI 
domains.  If  kept  up  to  date,  the  impact  on  all  domains  can  be  tracked  and  evaluated 
throughout  the  acquisition  cycle.  Areas  of  interest  to  Human  Factors  when  using  these 
tools  includes  workstation  ergonomics  or  interface  controls  and  displays.  The  Training 
domain  uses  these  representation  to  determine  the  requirements  for  future  simulations,  or 
the  content  of  training  materials.  Personnel  analysts  are  interested  in  these  tools  to 
investigate  any  potential  constraints  of  the  design  on  selection  of  future  personnel  (eg: 
crew  size  or  sensory  characteristics)  Safety  &  Health  Hazard  personnel  use  these  tools 
to  conduct  preliminary  safety  and  health  hazard  analysis  of  a  proposed  future  design. 

The  lower  tech  versions  of  workspace  and  interface  design  tools  consist  of  dimensioned 
drawings,  2D  CADD  files,  and  “Power  Point”  level  illustrations  of  interfaces. 

The  higher  tech  tools  for  workspace  and  interface  design  include  3D  CADD  modeling, 
computer  based  human  form  mannequin  software,  and  virtual  reality  based  reviews. 
Products  such  as  Safework  (Greenley  1999c)  provide  capabilities  in  each  of  these  areas, 
allowing  the  user  to  create  representations  of  workspaces  in  3D,  analyze  them  for 
conflicts  using  human  form  mannequins,  and  facilitating  review  by  future  operators  and 
maintainers  using  virtual  reality  techniques. 

3.2.3.4  Integrated  Tool  Sets 

The  “integration”  aspects  of  HSI  analysis  have  been  emphasized  several  times  throughout 
this  report.  As  the  analysis  sequence  and  analysis  tools  get  more  integrated,  there  are  two 
primary  benefits: 

1 .  The  analysis  becomes  more  efficient,  and  therefore  more  timely  and  cost 
effective. 

2.  The  impact  of  design  changes  on  all  HSI  domains  can  be  determined 
simultaneously,  resulting  in  a  higher  quality  of  assessment,  design,  and  design 
evaluation. 

Within  a  given  project,  there  is  a  logical  flow  of  analysis  between  the  three  primary 
groups  of  tools  described  earlier  in  this  section.  The  same  flow  applies  to  both  the  lower 
tech  and  higher  tech  tools  identified,  with  the  flow  of  data  having  the  potential  to  be  more 
direct  in  the  higher  tech  solutions. 

Figure  8  illustrates  the  flow  between  the  lower  tech  analysis  techniques.  In  this  case,  the 
task  flow  generated  through  scenario  analysis  forms  the  basis  for  the  evaluation  of 
crewstation  or  interface  drawings,  when  can  then  lead  to  the  creation  of  actual  mockups 
or  prototypes  that  can  be  reviewed  with  future  operators  or  maintainers  using  table  top 
analysis  or  some  form  of  usability  test/field  trial. 
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Figure  8:  Low  Tech  Integrated  Analysis  Tools 

Figure  9  illustrates  a  similar  flow  using  software  based  tools  that  share  data.  In  this  case 
the  task  flow  from  a  Task  Network  Model  (eg:  in  IPME)  can  be  exported  into  the 
mannequin  based  software  where  the  full  size  range  of  the  population  can  be  “asked”  to 
complete  the  task  sequences  in  3D  representation  of  a  workspace  generating  an  analysis 
of  any  layout  conflicts,  in  addition  to  information  on  the  physical  demands  placed  on 
different  sizes  of  the  population.  Similarly,  actual  operators  or  maintainers  can  be  asked 
to  “review”  the  design  by  “immersing”  themselves  into  the  environment  and  completing 
the  task  sequences  (using  various  sensors  on  their  joints,  and  head  mounted  displays).  In 
the  higher  tech  stream  of  analysis,  the  scenarios  and  task  flows  can  then  be  exercised  by 
real  users  in  full  scale  simulations  of  a  future  system,  after  which  operational  versions  of 
the  refined  system  can  be  developed  and  evaluated  in  field  trials. 

This  higher  tech  sequence  has  recently  been  exercised  by  the  Armour  community  to 
determine  the  requirements  for  future  armour  vehicles,  fire  control  systems,  and 
defensive  aids  suites  through  the  Advanced  Land  Fire  Control  System  (ALFCS)  and 
Pronghorn  programs.  Using  Defensive  Aids  Suites  (DAS)  as  an  example,  the  program 
started  with  identification  of  the  range  of  scenarios  that  Armoured  Personnel  Carriers, 
Reconnaissance  Vehicles,  and  Main  Battle  Tanks  might  have  to  operate  within.  These 
scenarios  were  then  used  to  as  the  basis  for  engineering  and  task  flow  analysis  to 
determine  the  basic  configuration  of  a  DAS  for  Canadian  vehicles.  This  DAS  was  then 
prototyped  on  paper  and  reviewed  with  users,  after  which  it  was  installed  in  the  full 
motion  ALFCS  crew  station  simulator  (the  interior  of  which  was  designed  using 
mannequin  based  software  tools).  Following  evaluation  with  crews  in  the  simulator,  the 
requirements  for  a  DAS  were  then  refined  and  developed  into  an  operational  prototype 
which  was  then  installed  on  an  AFV  and  evaluated  in  the  international  Pronghorn  Trials 
(TTCP  trial  involving  4  countries  hosted  by  Canada).  The  results  of  this  analysis 
sequence  then  generated  both  requirements  and  design  concepts  for  future  systems  that 
might  be  developed  or  acquired,  in  addition  to  identifying  other  HSI  requirements  related 
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to  doctrine,  roles  and  responsibilities,  task  flow  requirements,  interface  requirements, 
future  training  requirements,  and  some  personnel  issues  related  to  the  characteristics  of 
future  AFV  crews. 
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Figure  9:  High  Tech  Integrated  Analysis  Tools 
(from  Greenley  and  Beevis  1999) 


Fortunately,  the  basic  tools  and  technical  capability  to  conduct  all  of  these  low  and  high  tech 
analysis  exist  in  the  DND  community.  Future  efforts  to  integrate  analysis  process  and  tools  in 
these  areas  will  continue  to  make  it  easier  for  projects  to  manage  HSI  requirements  on  projects. 

3.3  Distribution  of  HSI  Information 

It  was  stated  earlier  in  this  report  that  one  of  the  basic  methods  for  determining  and  managing 
HSI  requirements  within  a  Directorate  was  to  use  literature  reviews,  and  electronic  archival  of 
relevant  requirements,  design  guidance,  and  performance  measures.  This  project  required  that  the 
team  review  the  requirements  for  electronic  sharing  of  this  type  of  information,  and  review  the 
options  for  electronic  distribution  over  the  DND  Intranets  or  perhaps  someday  the  Internet. 

3.3.1  Options  for  “Web  Based"  Distribution 

This  project  required  an  assessment  of  “Web  Based”  distribution  to  meet  the  user’s  requirements 
for  electronic  information  distribution.  In  this  context  “Web  Based”  refers  to  some  form  of 
browser  based  access  of  the  information,  whether  that  be  through  the  DND  Intranets  (eg: 

DW AN/DIN)  or  perhaps  someday  the  Internet  (World  Wide  Web). 

This  assessment  of  the  potential  for  Web  Based  distribution  of  information  was  completed  using 
AFV  related  HSI  information  as  a  “worked  example”.  This  means  that  the  analysis  of  presenting 
HSI  information  on  the  HSI  Web  Site  or  through  a  Web  Based  version  of  Soldier’s  Day  was 
conducted  using  Armour  System  SOR  information  as  the  example  data  set.  The  analysis  and 
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associated  recommendations  apply  to  all  environments,  based  on  the  project  teams  experience 
with  a  range  of  land,  air,  and  maritime  SORs. 

3.3.1. 1  HSI  Web  Site 

The  HSI  Information  Repository  is  a  web  site  that  has  just  been  initiated  on  the  Descartes 
system  within  DRDB  and  on  the  DIN  intranet  for  access  throughout  DND.  At  some 
point  in  the  future  it  is  intended  that  portions  of  this  site  will  be  accessible  by  the  outside 
community  through  the  Internet.  For  the  purposes  of  this  report,  this  site  will  be  called 
the  “HSI  Web  Site”. 

At  the  time  of  this  report  the  HSI  Web  Site  contained  basic  information,  such  as 
descriptions  of  HSI,  and  access  to  key  documents  that  outline  the  application  of  HSI  in 
defence  projects.  In  addition,  summaries  of  each  of  the  HSI  Tools  was  available.  Long 
term  strategic  plans  related  to  Human  Factors  and  HSI  related  R&D  were  also  included  to 
inform  of  the  DND  community  of  these  programs. 

Interviews  with  the  responsible  personnel  indicated  that  future  plans  for  the  HSI  Web 
Site  called  for  expansion  in  a  number  of  areas  including: 

•  Development  of  more  “web  pages”  to  summarize  the  HSI  field  and  each  of  the 
domains. 

•  An  illustration  and  description  of  the  recommended  HSI  Process,  once  it  is 
developed. 

•  An  indication  of  which  HSI  Tools  should  be  used  at  different  phases  of  the  HSI 
Process. 

•  Potential  access  to  some  of  the  HSI  Tools. 

•  Access  to  HSI  contacts  in  each  of  the  domains  throughout  DND  and  Industry  in 
Canada. 

Within  these  expansion  plans,  and  within  the  structure  of  the  HSI  Web  Site  itself,  there  is 
certainly  room  for  the  introduction  of  an  information  repository  for  HSI  related 
requirements. 

Analysis  by  the  project  team  concluded  that  it  would  likely  be  possible  to  create  some 
form  of  a  database,  with  a  web  based  interface,  that  would  allow  for  the  classification  and 
storage  of  HSI  related  references  that  would  permit  the  user  to  access  them  by  military 
environment  and/or  SOR  section  of  relevance.  The  military  environment  classification 
would  result  in  an  access  structure  similar  to  that  in  Figure  10  (using  AFV  as  an 
example).  Once  a  specific  arm  of  the  military  was  accessed  information  could  be 
presented  using  the  SOR  structure  (as  illustrated  in  Figure  11). 
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Figure  10:  Potential  Access  to  SOR  HSI  Information  Through  the  HSI  Web  Site 
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Figure  11:  HSI  Information  Structure  for  Web  Site  Using  AFVs  as  Worked  Example 


The  structure  in  Figure  9  suggests  for  any  one  operational  domain,  such  as  Armour 
Systems,  the  HSI  related  information  for  most  SOR  sections  is  common  across  the 
various  SOR’s  that  might  be  produced  for  that  domain.  However,  the  structure  and 
contents  of  the  performance  requirements  will  vary  with  each  class  of  system  to  be 
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acquired.  In  the  case  of  AFVs  as  a  worked  example,  this  means  that  different 
requirements  will  exist  specific  to  vehicles,  vehicle  subsystems,  mounted  soldier  clothing 
and  equipment,  and  crew  sustainment  related  procurement. 

The  advantages  of  the  HSI  Web  Site  method  for  distributing  information  is  that  it  is 
simple,  straightforward,  and  easier  to  maintain.  The  disadvantage  is  that  it  is  difficult  to 
link  related  requirements  in  the  mind  of  the  reader,  and  the  association  between  linked 
requirements  might  not  be  made.  The  pro’s  and  con’s  of  a  Web  based  version  of 
Soldier’s  Day  are  the  reverse. 

3.3. 1.2  Browser  Based  Version  of  Soldiers  Day 

Soldier’s  Day  is  a  multimedia  database  developed  to  present  information  on  soldiers, 
their  missions  and  tasks,  and  the  equipment  they  use  This  tool  was  developed  to 
promote  a  shared  understanding  of  soldiers  and  their  requirements  between  DND  project 
staff,  researchers,  and  industry  representatives.  Soldier’s  Day  was  originally  created  for 
the  dismounted  infantry  community,  and  is  used  by  personnel  involved  in  Clothe  the 
Soldier  and  the  Integrated  Personal  Clothing  and  Equipment  projects. 

The  current  version  of  Soldier’s  Day  is  distributed  using  a  CD  ROM.  This  project 
required  that  an  assessment  be  made  on  the  applicability  of  Soldier’s  day  to  distribute 
HSI  Information  for  SOR’s  (using  AFVs  as  a  worked  example)  and  to  do  so  using  a 
browser  based  interface  instead  of  a  CD  ROM. 

The  conversion  of  Soldier’s  Day  to  a  browser  based  application  has  been  reported  by 
experts  to  be  a  straight  forward  exercise  and  technically  feasible  (Greenley  1999c).  From 
a  user  perspective  this  would  be  desirable  as  it  would  ensure  maximum  access  throughout 
DND.  Presumably  a  web  based  product  would  also  decrease  maintenance  and 
distribution  resource  requirements. 

From  an  HSI  perspective.  Soldier’s  Day  is  an  effective  medium  to  distribute  the 
information  required  for  SOR’s.  The  current  Soldier’s  Day  product  has  information 
streams  for  Missions  and  Tasks,  Organization  and  Personnel,  and  Clothing  and 
Equipment.  These  same  information  streams  apply  to  all  military  environments,  and  the 
links  within  the  software  between  personnel  and  their  tasks,  or  tasks  and  the  related 
equipment  are  the  links  required  to  conduct  HSI  assessments  in  all  environments.  The 
only  major  structural  change  required  is  the  addition  of  an  information  stream  for 
“vehicles/crew  stations”  (in  the  case  of  AFVs)  Once  a  vehicle  based  information  stream 
is  added  the  Soldier’s  Day  product  will  then  be  applicable  to  all  vehicles,  including  land 
vehicles,  aircraft,  and  ships. 

Figure  12  illustrates  the  concept  of  the  addition  of  a  “vehicles”  information  stream  to 
Soldier’s  Day,  presented  in  a  browser  based  interface. 
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Figure  12:  Concept  for  Browser  Based  Version  of  Soldiers  Day 
with  the  addition  of  a  Vehicles  Information  Stream. 


Figure  13  illustrates  the  current  structure  of  the  Soldier’s  Day  database.  This  figure 
indicates  that  many  of  the  HSI  domains  are  already  covered,  including  scenarios, 
missions,  tasks,  key  roles,  key  tasks,  user  characteristics,  safety  and  health,  equipment 
requirements,  and  related  references.  Any  military  environment  that  was  to  adopt  the 
Soldier’s  Day  tool  as  an  information  repository  would  then  be  able  to  enter  and  track  the 
HSI  related  requirements  in  these  categories. 
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Figure  13:  Current  Soldier’s  Day  Structure 

However,  there  are  some  categories  missing  that  are  necessary  to  complete  the  full 
picture,  in  addition  to  some  recommended  enhancements  to  support  the  larger  scope  of 
HSI  compared  to  the  original  focus  on  Human  Factors,  which  is  only  one  HSI  domain. 
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The  recommended  enhancements  to  the  Soldier’s  Day  structure  are  illustrated  and 
highlighted  in  Figure  14,  and  include: 

1 .  There  should  be  links  to  relevant  references  throughout  the  database. 

2.  Modification  for  a  particular  domain  will  require  minor  modifications  to  match 
organizational  and  personnel  structure.  Figure  14  illustrates  the  modifications 
required  to  adapt  Soldier’s  Day  to  a  Crewman’s  Day  product  for  the  Armour 
community. 

3.  A  vehicle  stream  of  information  is  required.  This  stream  must  use  the  multi- 
media  capabilities  of  the  system  to  present  information  on  the  vehicle,  its  crew 
stations,  and  the  equipment  used  at  each  crew  station.  Within  this  stream  links 
must  be  made  to  the  personnel  that  operate  each  crew  station  and  the  primary 
tasks  performed  at  each  station  using  the  equipment  identified.  Figure  14 
illustrates  these  required  changes  using  the  AFV  example,  however  the  same 
principle  applies  to  the  other  military  environments  (eg:  in  a  ship  this  stream 
would  identify  decks,  spaces,  and  then  equipment  or  consoles  in  each  space). 

4.  For  each  military  environment,  the  opportunity  for  HSI  related  analysis  tools 
should  be  investigated.  The  current  Soldier’s  Day  provides  a  Load  Carriage 
Calculator  under  Clothing  and  Equipment  to  allow  the  user  to  “what  if’  the 
impact  of  altering  the  items  to  be  carried  on  the  demands  of  different  sized 
soldiers.  Figure  14  proposes  that  a  Stowage  Calculator  be  provided  for  A 
Crewman’s  Day  to  allow  the  user  to  “what  if’  the  impact  of  adding  new 
equipment  on  the  stowage  capacity  of  different  vehicles. 

5.  All  references  that  are  used  in  any  particular  version  of  Soldier’s  Day  should  be 
classified  with  a  tag  by  SOR  category. 

6.  The  “About  Human  Factors”  section  of  the  tool  should  be  extended  to  provide 
information  “About  HSI”.  If  the  tool  is  to  become  web  based,  then  the  About 
HSI  section  should  likely  be  covered  off  by  the  content  already,  or  soon  to  be, 
available  on  the  HSI  Web  Site. 
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Figure  14:  HSI  Enhanced  Soldier’s  Day  Modified  for  AFV  Systems  as  Worked  Example 
(AFV  and  HSI  Enhancements  Highlighted) 

3. 3. 1.3  Soldiers  Day  SOR  Builder 

Section  3.3. 1.2  reviews  the  necessary  changes  to  Soldier’s  Day  to  include  information  for 
all  HSI  domains,  and  to  provide  a  structure  to  support  all  military  environments.  The 
reader  should  note  that  this  analysis  did  not  recommend  that  the  Soldier’s  Day  product  be 
restructured  to  align  itself  with  the  sections  of  the  new  SOR  template,  but  instead  to  insert 
the  information  inside  the  existing  database  structure  with  SOR  category  flags  on 
references  only.  The  rationale  for  this  is  that  the  current  Soldier’s  Day  structure  was 
developed  over  several  years  with  considerable  input  from  the  user  community.  This 
community  includes  DND  project  staff,  researchers,  industry  designers,  manufacturers, 
and  consultants.  Altering  the  structure  to  specifically  support  SOR  developers  would 
decrease  the  utility  of  the  system  to  the  other  user  categories. 

It  is  therefore  recommended  that  an  SOR  Builder  tool  be  developed  as  an  “add  on”  to  the 
Soldier’s  Day  product.  Such  a  tool  would  take  advantage  of  the  links  already  inside 
soldiers  day  to  extract  the  HSI  related  information  available  to  support  the  development 
of  a  specific  type  of  SOR. 

For  example,  if  a  DLR  3  user  was  using  Crewman’s  Day  to  develop  the  requirements  for 
a  new  sight  they  would  access  the  SOR  Builder  and  indicate  that  they  wanted  to  learn 
about  HSI  related  requirements  for  a  new  sight  (or  would  select  an  in-service  sight  that 
they  wanted  to  replace  using  the  Crewman’s  Day  sturcture).  Once  selected  the  software 
would  then  be  able  to  follow  the  links  in  the  software  to  identify  the  users  of  that  sight, 
the  characteristics  of  those  users,  the  tasks  the  sight  is  used  for,  the  scenarios  that  the 
sight  is  used  within,  the  crew  station  characteristics  where  the  sight  is  used,  any  known 
deficiencies  with  the  current  sight  or  comparable  sights  (on  this  vehicle  or  related 
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vehicles),  etc..  Once  this  search  was  complete  the  SOR  Builder  tool  would  generate  a 
series  of  links  by  SOR  category  that  would  allow  the  user  to  jump  into  different  sections 
of  the  Soldiers  Day  database  to  extract  information  of  relevance  to  their  SOR  (which  can 
be  cut  and  pasted  into  word  processing  software).  This  concept  is  illustrated  in  Figure 
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Figure  15:  Concept  for  SOR  Builder  Add-On  to  Soldier’s  Day  Software 
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4  Conclusions  and  Recommendations 


This  report  was  developed  to  provide  some  guidance  for  addressing  the  Human  Systems 
Integration  content  requirements  of  DND  SORs  and  to  discuss  the  options  for  electronic 
distribution  of  HSI  related  information. 

In  general,  the  inclusion  of  HSI  related  requirements  in  SOR’s  appears  to  be  straight  forward 
based  on  a  systematic  analysis  of  future  systems,  within  the  context  of  future  scenarios  and 
operational/support  concepts.  It  is  recognized,  however,  that  it  will  take  time  for  such  analysis  to 
become  practiced  and  routine  throughout  all  DND  environments.  It  is  recommended  that  the 
DRDB  community  support  any  efforts  to  ensure  that  HSI  is  included  in  SOR’s  over  the  next 
several  years  and  that  early  samples  be  provided  on  the  HSI  Web  Site  as  examples  for  other 
projects  to  learn  from. 

In  addition,  it  is  recommended  that  the  feedback  on  SOR  structure  and  content  related  to  HSI 
issues  outlined  in  this  report  be  integrated  into  future  versions  of  the  SOR  template  and  associated 
guidelines. 

This  project  has  concluded  that  the  basic  process  for  analysis  and  validation  of  HSI  related 
requirements  is  known,  however,  a  more  detailed  integrated  HSI  process  is  still  required.  It  is 
recommended  that  such  a  process  be  developed,  and  it  is  recognized  that  DND  is  already 
initiating  efforts  to  do  so. 

It  has  also  been  concluded  that  the  key  to  conducting  an  integrated  analysis  is  to  use  techniques 
and  tools  that  allow  a  core  analysis  of  (i)  Operational  Experience,  (ii)  Scenarios/Functions/Tasks, 
and  (iii)  Workstations  or  Interfaces  to  be  shared  by  each  of  the  domains  of  HSI.  This  shared 
assessment  increases  the  efficiency  and  accuracy  of  analysis  and  ensures  that  all  requirements  are 
kept  up  to  date  throughout  the  acquisition  cycle.  It  is  recommended  that  tools  and  techniques 
should  continue  to  be  developed  to  facilitate  the  sharing  of  analysis  between  these  three  primary 
assessment  areas,  and  it  is  recognized  that  DND  is  already  initiating  efforts  to  do  so. 

It  is  recommended  that  the  Armour  community,  in  conjunction  with  other  military  environments, 
consider  the  conversion  of  Soldier’s  Day  to  a  web  based  product,  with  the  introduction  of  an  add 
on  module  for  Building  SOR’s.  This  solution  is  preferable  to  simply  creating  annotated 
bibliographies  accessible  on  the  Intranet,  however,  both  electronic  distribution  mechanisms  could 
be  introduced  in  parallel. 
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conjunction  with  other  military  environments,  consider  the  conversion  of  the  Soldier's  Day  software  too!  to  a  web  based 
product,  with  the  introduction  of  an  add  on  module  for  building  SOR’s. 
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